iT邦幫忙

2024 iThome 鐵人賽

DAY 1
1


(此圖片由 AI 生成)

很久沒參加鐵人賽了,筆者我自今年初開始接觸專案管理類的書籍(非 PMP 相關),當時還沒想考認證,直到 3 月中上了 PMP 實體課受到啟發,到前陣子 7/30 通過 PMP 國際專案管理師的認證,接觸到 PMP 知識並通過認證共耗時 4 個半月。


(credly 上含本名的的認證徽章: https://www.credly.com/badges/603a2f62-4919-438a-81ba-737eea1724a1/linkedinprofile)

考取認證後剛好鐵人賽開賽,很糾結要不要以此作為主題,最後想想,既然我在我的 Heptabase 筆記軟體都寫了破百張筆記卡片了,有什麼理由不參加呢?所以讓我來和大家分享這陣子的心得吧!

學習與考照的動機

筆者我最初並沒有抱著我要「考取認證」這種想法而報名上專案管理的課程,當初學習的動機是:

  • 希望更了解專案管理知識,好更宏觀的看待事情發展。
  • 發現實體班(此系列幾天後會介紹)的學費比預期便宜,很適合試水溫學習 PMP/PMBOK 知識。
  • 直到課程末段越學越有趣,才確立自己想要考取認證得本心。

關於此次鐵人賽名稱

這裡先解釋一下此系列文的主題名稱「工程師,我們也可以學習 PMP !」

PMP 是指 Project Management Professional 國際專案管理師證照,這個證照是要「考」的,原本標題是「工程師,我們也可以考取 PMP !」後來我認為單純作為工程師,理解有這一系列知識,只學習不考照也是沒問題的,所以將「考取」置換成「學習」兩個字。

但如果要將「考取」置換成「學習」,講「學習」專案管理,那應該要把標題改成「工程師,我們也可以學習 PMBOK !」才對,那接下來就會是一堆人看到標題困惑, 例如 PMBOK 是什麼? 既然這個 iThome 鐵人賽系列是「證照」,還是要切題一下,遂改成「工程師,我們也可以學習 PMP !」

我並不是證照(越多越好)派的擁護者,話雖如此,此系列文還是會提到一些考取 PMP 的內容,再麻煩大家選擇性觀看你們有興趣文章段落就好,謝謝。

四個此系列文的預防針

在開始此系列文章前,必須先講四件事,對齊觀看者的預期:

1.學習、考取 PMP 與非 PM 職位的專業能力沒有正相關

工程師學習專案管理,不代表這個人在本職程式工作做得好或差,這也可以是自我提升的一種方式,力求以其他角度、更多知識點來審視專案。

程式撰寫是一門獨立專業、UI 設計是一門獨立專業、行銷企劃..etc 這些都是獨立專業彼此要分開來看的,當然,專案管理也一門獨立的專業,不會因為你程式寫得好、UI 畫的好,專案管理連帶變得很好,沒有這回事,學習或考取 PMP 與非 PM 職位的專業能力是沒有正相關。

2.君子宣言:注意智慧財產權

報名 PMP 需要有教育訓練時數前置條件,而筆者的教育時數是通過上實體課程取得的,實體班內部有共享雲端課程資源,如果鐵人賽直接拿裡面的內容分享,是非常不道德的事情。

我覺得實體班授課老師教得好,上課節奏也很好,也推薦大家報名(實體班心得在後面幾天的鐵人賽文章會提到)。當然,只要觀點一樣,一定會有類似的內容,故這裡君子宣言要表示的是:我會盡量拿捏好「主觀分享」這件事情,不會做外流之事,很多資訊點到就好。

3.此系列文章不是替「考證照文化」說話

這系列文章雖是考照心得分享,亦有內容分享考照資訊,但不代表我完全認同考證照這件事,就是這麼矛盾

網路上隨便搜尋都可以找到為什麼不考 PMP 的文章。而且報考 PMP 還要花超過一萬元報名費,實在是不便宜。

要知道證照無用論是與該證照背後知識點與發照組織信任度有關,舉例上一秒工程師朋友還跟你說 AWS 證照真香,下一秒和你說考 PMP 這個幹嘛,所以這系列文章僅提供給那些對專案管理或是 PMP 考照有興趣的人參考,不代表筆者認同考照文化這件事。大家也可以只學習 PMP 背後( 基於 PMBOK 的 )知識 ,不考照,這也是沒問題的!

4.此系列不會講完 PMBOK7 所列的所有管理與議題探討

ITHOME 鐵人賽過往也有不少以 PMP 為主題的優秀參賽文,例如: https://ithelp.ithome.com.tw/users/20009729/ironman/238

作者大大當年 30 篇有參考遵守當時的 PMBOK4 的內容,現在看仍然覺得很厲害,只是對我來說:30 天鐵人賽不可能講得完所有東西,尤其我會帶入上實體班、應考 PMP 的心得,這些主觀心得扣一扣,30 篇能基於 PMBOK 的內容其實沒有很多。

這裡可以肯定的說,此 30 篇必定有很多 PMBOK 內容的遺珠之憾。還是希望大家多看主觀心得分享的部分,因為純理論其實 Google 搜尋或看書、上實體或線上課程都會提到。

結語

平常我們工程師不斷強調有解決問題的能力,有趣的是:當遇到專案管理相關問題時,卻選擇不作為,因為那是 PM 的事,因為那是主管的事。於是工程師抱怨,在抱怨完後日子照樣過,下一次遇到類似問題時再繼續抱怨,直到離職前陷入永無止境的循環,沒有任何作為或行動。

不作為定義:現實想要改變涉及制度的事情,所需要成本可能很高,還涉及職等與上下權力關係,那已經是另一個議題了,只是表示去掉「外部因素」只看自己就好,自己在抱怨後沒有去學習或嘗試了解,只會一直抱怨卻不去理解,那就是一種不作為。

我想對看到這篇文章的工程師夥伴們說:如果你對公司專案管理制度「有一些想法」或者曾經萌生過學習或考取 PMP 的念頭,建議就直接行動吧,我們不能改變公司,至少能嘗試改變自己,試著多學習、擴寬自己角度來理解與分析。


目錄

第一段:PMP 與課程

  • Day01 楔子
  • Day02 學習與考取 PMP 得不到什麼? PMP 不是萬靈丹
  • Day03 PMP簡介:PMI 與 PMP
  • Day04 PDUs 與考照前的教育訓練時數是不同東西
  • Day05 教育時數與課程心得(上)
  • Day06 教育時數與課程心得(下)
  • Day07 我在學習過程使用的其他資源

第二段:PMP 的核心

  • Day08 什麼是專案?
  • Day09 專案的五大流程群組
  • Day10 專案的十大知識領域
  • Day11 專案的十二項原則
  • Day12 專案的八大績效

第三段:一點點的 PMP 理論

  • Day13 專案的拆解:什麼是 WBS 工作分解結構?
  • Day14 專案與利害關係人
  • Day15 專案與溝通:如何進行有效溝通?
  • Day16 專案與風險:如何面對風險
  • Day17 專案與範疇:如何應對專案變更
  • Day18 專案與時程:時程變短或需求增加怎麼辦?

第四段:一點點的敏捷

  • Day19 敏捷專案管理:三大核心角色
  • Day20 敏捷專案管理:產品待辦清單與衝刺清單
  • Day21 敏捷專案管理:衝刺審查
  • Day22 敏捷專案管理:回顧會議
  • Day23 再一次我會怎麼建議:敏捷、迭代與增量

第五段:PMP 的考取

  • Day24 來點圖表!學習 PMP 中有提到的各種圖表(上)
  • Day25 來點圖表!學習 PMP 中有提到的各種圖表(下)
  • Day26 報名 PMP 考試
  • Day27 考試當天
  • Day28 考題心得
  • Day29 考取 PMP 之後:PDUs 獲得方式
  • Day30 心得-持續前進、持續相信

下一篇
Day02 學習與考取 PMP 得不到什麼?PMP 不是萬靈丹
系列文
工程師,我們也可以學習 PMP!12
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言